Definition of Done Done Done - Warum Akzeptanzkriterien auch auf realem Nutzungsverhalten fußen sollten

Product Owner haben oft kaum Zeit, Backlog Items zu priorisieren und eindeutige Akzeptanzkriterien zu schreiben. Außerdem ist das Einbeziehen klassischer Research Methoden in die kurzen, agilen Sprintzyklen häufig nur schwer möglich. Daher wird nur selten Nutzerfeedback in die iterativen Entwicklungsschritte integriert. Die in der Praxis vorherrschenden Akzeptanzkriterien, die die vielzitierte „Definition of Done“ bilden sollen, bieten Product Ownern nur eine scheinbare Sicherheit: eine User Story kann zwar umgesetzt („Done“) und geliefert worden sein („Done Done“), wird aber im Feld dennoch nicht vom Nutzer akzeptiert. Wirklich fertig ist aus UX Sicht nur diejenige User Story, die bewiesenermaßen die Akzeptanz des Nutzers findet („Done Done Done“). Doch wie kann das dritte „Done“ in agilen Projekten erreicht werden? Woher wissen wir, wann eine umgesetze User Story akzeptiert wird? Mit welchen Methoden kann dies auch in schnelllebigen, agilen Projekten festgestellt werden?

Im Forschungsprojekt Opti4Apps wurde ein neuartiger Ansatz der Nutzungsdatenanalyse entwickelt, der automatisiert Daten auf der Basis von User Stories sammelt und aggregiert. Zu Beginn des Forschungsprojektes zeigt sich, dass ein Mindestmaß an Kontextinformation benötigt wird (wie z.B. “Welcher Nutzer agiert in welcher Rolle mit welchem Ziel?“), um auf Basis von Nutzungsdaten sinnvolle Entscheidungen ableiten zu können. Letztere Information sollte im agilen Entwicklungsprozess eigentlich schnell verfügbar vorliegen – nämlich in Form einzelner User Stories. Diese gehen jedoch kurz nach der Implementierungsphase meist verloren, da umgesetzten User Stories in der Praxis oft keine weitere Relevanz mehr beigemessen wird. Die entwickelte Methode erreicht durch die Definition realer Nutzerakzeptanzkriterien für jede User Story, dass deren Erfüllung über den Vergleich von Soll- und Ist-Werten messbar wird. Somit können auf einen Blick Entscheidungen bezüglich der Nutzerakzeptanz aller für den Sprint relevanten User Stories und bezüglich der nächsten Backlog-Priorisierungen getroffen werden.

Im weiteren Verlauf des Forschungsprojektes wurden außerdem Visualisierungsmethoden getestet, um jedem Product Owner einen möglichst einfachen und leicht verständlichen Zugriff auf die analysierten Daten zu gewähren, damit dieser eigenständig Entscheidungen auf Grundlage der Daten treffen kann.
Die „Definition of Done Done Done“ hat für Product Owner also den entscheidenden Vorteil, dass sie nicht nur glauben müssen, dass eine User Story ausreichend reif beim Nutzer aufschlägt, sondern sie dafür auch nachweisliche und quantitative Bestätigung im Feld bekommen.

Die User Story-basierte Nutzungsdatenanalyse ergänzt den „Continuous UX“ Baukasten (T. Immich, „Continuous UX - Lean und Large unter einem Dach,“ in Tagungsband der Mensch & Computer 2018, Dresden, 2018.), um in agile Prozesse regelmäßig und automatisiert Nutzerfeedback und Entscheidungsverbesserungen einzubinden. Im Vortrag wird das Vorgehen im Forschungsprojekt dargestellt. Anhand zweier Apps wurde in einer Vor- und einer Hauptstudie die oben beschriebene Methode entworfen und optimiert.

zurück zum Programm